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(57) Abstract: A virtual server (54) which automates the retrieval of dynamic content for a web page and applies previously gener- 
ated style (25) and content definition (28) sheets to format the content is disclosed. In the embodiment shown, an HTML document 
converted into an XSL style sheet document containing the static formatting and an XMLDTD document defining the dynamic con- 
tent are created at design time. These identify which parts of the formatted document should be considered dynamic content and 
which should be considered as static. At run time, the invention automatically generates and serves virtual, hierarchically structured 
documents from structured data stored in a variety of data schemas. The style sheet (25) and content definitions (28) are applied to 
the data so that a virtual display document is created and sent in response to a user's request The embodiment shown also allows data 
transformations to be defined visually. Data retrieval and processing are pre-compiled and optimized when virtual server process is 
started 
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Description 

Virtual Server System For Dynamic Content In World Wide Web Pages 
Technical Field 

The present invention relates generally to the field of creating interactive World 
5 Wide Web display documents for use over the Internet and more particularly to 
a virtual server for automatically generating web pages containing dynamic 
content. 

Background 

The explosive growth of the Internet and the World Wide Web (the Web) in the 
10 last few years has been accompanied by an ever-increasing use of the Internet and 
the Web for business and commercial purposes. However, most of the tools, such 
as the Standardized General Markup Language "SGML" and Hypertext Markup 
Language "HTML" languages and page generation tools which have been 
developed to allow individuals and companies to create Websites, assume that the 
15 content of a Website will be relatively static. HTML, for example, does not provide, 
any syntax for dynamic content. For a retail website designed to display a retail 
catalog and price list that changes only once every few months, this tends not to 
be a problem, if products and prices do not change more rapidly. However, as 
more dynamic business applications are projected for the web, the need to 
20 transmit "live," current data through the website has increased dramatically. The 
proposed extensible Markup Language "XML" and extensible Style Language 
"XSL" formats should assist in standardizing the format for dynamic content but 
there are few, if any, tools which allow a statically defined website to handle 
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dynamic content changes readily. Consequently, those businesses seeking to 
develop such applications will typically need to hire skilled information 
technology (IT) resources to do so. 

The illustration in Figure 2A(Prior Art) shows the different types of IT skill levels 
5 that this might entail. Presently, the simplest IT skill level is shown at level AA, 
where WYSIWYG (What You See Is What You Get) design tools such as 
DREAMWEAVER™ and FRONTPAGE™ provided by Microsoft, allow graphic 
designers to design web pages and to control the contents of them. Ideally, as 
level AA indicates, a web designer is likely to be able to use HTML (Hypertext 

10 Markup Language). This is a relatively simple, easy to use language that allows a 
web designer to "mark up" text and graphics in a web page so they will display as 
desired at the user's web browser. As the WYSIWYG term implies, WYSIWYG 
tools allow a designer to manipulate symbols and graphics in such a way that as 
the designer places them on a webpage, they can be viewed as they will appear to 

15 a user. For the typical static content of most websites these tools have eliminated 
the need for training the web designer in the details of IT and more advanced 
programming skills. 

To the extent that the owner of a commercial website wishes to include the kind of 
dynamic content associated with many business applications, some higher level of 
20 IT skill will usually be required to accomplish this. As shown in Figure 2 (Prior 
Art), as the IT skill level needed ascends the pyramid shown, resources tend to 
become scarcer and usually more costly. This is true even with the advent of XML. 
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For example, if a user wants to develop an application that permits use of a 
volatile, rapidly changing internal database over the Internet, it is very likely that 
dynamic queries made against the database will turn up a variety of responses. 
HTML does not allow a designer to specify content as dynamic. Most present 
5 design tools have non-standard extensions to HTML that allow a designer to 
include some dynamic data. However, since these are non-standard extensions, 
the designer may be locked in to one tool. Also, they usually require additional 
training of the designer. Most problematic, however, is the fact that they are 
likely to intermingle data access design logic with display design. 

10 These tools also may or may not be able to handle some of the more complex 
types of repeating fields in dynamic data. Problems frequently arise when the 
application under development attempts to map columns C1-C5, in a database, 
such as database 00 in Figure 3(Prior Art) to field F mappings in a web page 15, 
when the columns or the field contain hierarchical node components. Thus, Fl in 

15 webpage 15 may actually require several hierarchical sub -fields F1-F4 to display 
the hierarchy of subset data found in a column C in database 00. Conversely, in 
some cases a query made by a user against the database 00 may require the data 
access design to resolve repeated rows of data from database 00 into an 
aggregated document for display on the webpage 15. In order for such multiple 

20 results to be displayed on webpage 15, additional custom programming beyond 
the IT skill level of the typical web designer has usually been required. 

The prior art tools usually put dynamic data directly into HTML formatted pages 
physically stored on the website, if they are able to handle dynamic data. Today, 
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many users would prefer to be able to put the dynamic data into XML format 
first, to take advantage of its tag labeling features. HTML only defines formatting 
- -XML allows a user to classify the data using tags. For example, HTML only 
allows a user to format the appearance of the words "Charles Dickens", while 
5 XML allows a user to tag those words to indicate he is an author. 

Present techniques for solving the IT problem, even with existing tools, usually 
involve having an IT professional who is skilled in Java or C++ or other languages 
work in serial with the web designer. Typically, the IT professional develops data 
access logic to provide the data for the web designer's page design. As shown in 
Figure 2B(Prior Art) this data access logic is usually embedded in the server 
enabled page 40 as a data access component 42 (an object or piece of code) or as a 
server side call 44 within a static HTML document. This means that the page 
design or "look and feel" of the website or application is tied together with data 
access and processing and vice versa. Page designers cannot re-design for look 
and feel without also affecting the data access design. Data access logic cannot be 
re-designed without also affecting the page design. 

This also means designers and IT professionals must interact more than they 
might otherwise need to do. In normal developments this occurs serially. That is, a 
page designer may propose a layout which then has to be reviewed and 
20 accommodated by the data access IT personnel. If IT personnel think data access 
logic can be developed or modified to accomplish it, IT approves it and proceeds 
with development. If IT does not approve, several discussions may be needed to 
identify compromise solutions. Similarly, changes in the data access logic which 
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might necessitate changes in the page document display will have to be reviewed 
and accommodated by the graphics page designer. There can often be several 
iterations back and forth before final common specifications are agreed upon. This 
tends to cause delays and loss of productivity, as well as a greater chance for 
5 design errors. 

With the interdependences that exist between page design and data access design 
in this approach, other errors can arise easily based on misunderstandings 
between persons with different skill sets. What may seem to be an obvious page 
design requirement based on the data access logic design may not be obvious to a 
10 graphics designer handling the web page. Similarly, a page design that optimizes 
attractive display and ease of use may not appear so useful to the data access logic 
personnel if it makes their jobs more difficult. These discrepancies may not 
become apparent until well into the development cycle when the page design is 
first used in connection with the data access design. 

15 Similarly, the business application being developed for the Internet may require 
that the web page designer and the data access designer allow a user to 
conditionally extract data for certain kinds of queries. In these cases, one field in 
the webpage may need to relate back to many columns of data in the database 00 
backend or vice versa, depending on the data values or the context of the query. 

20 If the business wants to enable the web browser user to update a database 00, 
additional complications can arise. Is the update an addition, a deletion, or a 
change? How is the data sent to the web server handling the webpage and the 
database to be used? What formats are required? The web server protocol HTTP 
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used by designers of HTML documents operates on the principle of "request and 
return". This means web servers can deliver rich formatted information inside the 
web pages they serve, but they can only accept relatively simple information from 
within a request that is sent by a user at a web browser. Specifically, when a web 
5 server receives information, it natively accepts only a simple list of HTML 
parameters and their values. These parameters are either attached to the URL 
directly or are sent separately from the URL when submitted from a form using 
the POST method. Present attempts to address this problem with existing tools 
require even more special programming and exceptions. 

10 For more complex business applications, automatic retrieval and processing of all 
information needed to make successive data access requests based on the results 
of the current request may be desired. In this kind of system, the application 
allows the user at a web browser to submit requests that "drill down" through 
multiple levels of data detail in the backend database 00 to find very specific data 

15 knowing only general information about its location. The problem faced by the 
data access IT person and the graphics person occurs when they try to tnake the 
system automatically determine the navigational information required about the 
location of the specific data, so that each successive request can be defined and 
altered independently of the other requests, but in such a way that the links 

20 between them are automatically maintained. For example, if the database contains 
a list of employees, and the user at a web browser only knows that she wants to 
find an employee named Joe, who lives in the Northeast, she might search the 
database for all employees named Joe. To find a specific one, the user might 
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request all those named Joe Smith. When the user sees the list she sees one living 
in Boston Massachusetts and one in Nashua, New Hampshire. If she remembers 
the area code, she can ask again to see the one with area code 603, which is the 
New Hampshire Joe Smith.Retrieving all the necessary information required so 
5 that a user can perform this kind of search is a significant challenge for present 
tools. 



Recent industry projections indicate that the creation of a simple website with 
static displays can cost a company anywhere from several thousand US dollars to 
hundreds of thousands of dollars. Many business organizations may also have 
10 existing internal databases and applications programs they have spent thousands 
or millions of dollars developing. 

At present, programming language tools for the Web, such as ASP™, provided 
by Microsoft and COLDFUSION™ 's CFML™, provided by Allair, attempt to 
offer businesses a way to integrate the dynamic content of backend databases 

15 with statically defined website pages, but these tools involve using a specially 

developed proprietary language with its own complexity and hence, the need for 
a higher IT skill level. CFML, for example, has over 200 different commands a 
designer might need to learn. These tools as well as custom programmed efforts 
written in Java or C++ also tend to require the embedding of code in the webpage 

20 documents. This code is usually executed at run-time each time requests are made 
for dynamic data. As seen in Figure 2B(Prior Art) this can also slow down the 
overall execution of queries made at run-time over the Web. 
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Present attempts to design or modify web pages to incorporate dynamic data 
content are thus hampered by the potential need for higher, more expensive and 
scarcer IT skill levels, costly development times and delays, and final products that 
may be comparatively slower in execution time. Additionally, some current 
techniques require a user to include programs written in proprietary languages or 
custom-developed programs. 
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Summary 

A virtual server system for generating dynamic content and a display document 
therefor to be sent over a network is disclosed which automates the retrieval of 
dynamic content and uses previously defined style and content definition sheets 
5 to format the display document. In the embodiment shown, dynamic data is 

accessed from a database, in any of a number of formats and schemas, using data 
access definitions and parameters generated at design time. The virtual server 
uses a previously defined XSL style sheet document containing the static 
formatting desired and an XML DTD document defining the dynamic content to 
10 be applied to the data to generate and serve the requested display document. 

It is an aspect of the present invention that no physical display document is stored. 

It is another aspect of the present invention that a display document can be 
generated at runtime by a virtual server which not only creates the document but 
also accesses any dynamic data needed in the display. 



WO 01/18656 PCT/US00/24695 

-10- 

Brief Description of the Drawing s. 
Figure 1 A is a block diagram of the present invention. 
Figure IB is a schematic drawing of the present invention in use. 
Figure 1C is a block diagram of illustrative syntax used by the invention. 
5 Figure ID is a block diagram of illustrative syntax used by the invention. 
Figure IE is a block diagram of illustrative syntax used by the invention. 
Figure IF is a block diagram illustrating the formatting of repeating rows. 
Figure 1G is a block diagram illustrating the formatting of nested tables. 
Figure 1H is a block diagram illustrating the formatting of nested tables. 
10 Figure II is a block diagram illustrating the formatting of repeating bulleted lists. 
Figure 1J is a block diagram illustrating the formatting of repeating form 
elements. 

Figure 2A(Prior Art) is a block diagram of skill levels required by the prior art. 
Figure 2B(Prior Art) is a block diagram of prior art techniques. 
15 Figure 3 (Prior Art) is a schematic diagram of a prior art access to a database, 
illustrating a problem. 

Figure 4A (Prior Art) is a block diagram of server processing in the prior art. 
Figure 4B is a block diagram of server processing using the present invention. 
Figure 4C is a block diagram of the present invention in operation at runtime. 
20 Figure 4D is a block diagram of a visual mapper of the present invention. 
Figures 5 - 15 are flow and block diagrams of the present invention. 
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Detailed Description of the Invention 

In Figure 1 A an overview of the present invention is shown. An input page 15, 
which is being designed by a web designer, is depicted. Web pages such as input 
page 15 designed in standard HTML for the World Wide Web usually contain 
5 formatting definitions 15a and static content 15b. Working in conjunction with the 
web page designer's choice of designer tool 13, the present invention's dynamic 
content identifier (DCI) 18 evaluates the syntax used by the designer to create the 
page. Using a special, simplified syntax and context analysis discussed below, DCI 
18 splits input page 15's elements into those which are static content and those 

10 which are dynamic content. In the embodiment shown, DCI 18 creates an XSL 
compliant style sheet 25, which describes the formatting 26 of the static content of 
input page 15. DCI 18 also creates a dynamic content definition 28, in XML 
compliant Document Type Definition (DTD) format. At design time a data access 
designer uses page request definition generator 19 of the invention to create data 

15 access definitions 32b, which are input parameters for the invention's page request 
object handler 32. When a web page such as input page 15 is requested from the 
present invention's virtual server (described below) at runtime, the invention's 
server applies style sheet 25 and dynamic content definition 28 to the content 
retrieved dynamically from a database to produce a fully formatted HTML page. 

20 This is performed by server objects 30, which include server and data access core 
code 31 and a page request object handler 32. Page request object handler 32 in 
the embodiment shown includes a handler routine which accepts parameters 
generated at design time by page request definition generator 19. These 
parameters define how to access the data in a database and how to map that data 

25 into XML format. The parameters also define how to connect to the database, how 
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to login, how to generate queries against it, and so on. 
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Despite the fact that HTML at present has no support for dynamic content, the 
present invention's dynamic content identifier (DCI) 18 allows designers to define 
all formatting for dynamic content using existing standard HTML tags, using any 
5 type of HTML editor or designer tool 13. In the embodiment shown, DCI 18 
operates as a separate tool from designer tool 13. However, it could also operate 
as a subset or extension of a designer tool 13. DCI 18 recognizes specially prefixed 
field names and attributes, and contextual data to automatically generate an XSL 
compliant style sheet from the HTML input page 15. 

10 Figure 1C illustrates some of the general types of specially prefixed field names 
and attributes. In the embodiment shown, a default prefix 80 such as "psx" can be 
used by the web designer to identify dynamic content. While the examples shown 
here use psx, another prefix could be supplied by the designer at the initial 
configuration of the system. 

15 Still in Figure 1C, a web designer can use the default prefix 80 with any field 

names 82 that conform to the XML syntax. Note that these field names are written 
in HTML by the designer, but conform to XML syntax. Since XML field name 
syntax requires all fields to share a common ''root" node name, the present 
invention automatically generates a "root" node name for all fields in the HTML 

20 document. The root node name comes from the base names of the HTML display 
document that is being analyzed by DCI 18. For example, assume that in Figure 
1C, field 82c "psx-name/first" is contained in an input page 15 called person.htm. 
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In this example, the present invention gives field 82c the full name 84 of 
"person/name/first" and the associated DTD document 86 is called "person.dtd". 
In this example, the root node name is "person/' Any field names 82 in the 
HTML document input page 15 which already use the correct root node name are 
5 not altered by DCI 18. 

Turning now to Figures ID, and IE, two types of special syntax recognized by the 
present invention are illustrated. Figure ID illustrates exposed syntax and Figure 
IE illustrates hidden syntax. 

First, in Figure ID, the present invention enables the web designer to use the 
10 default prefix 80 with fields which are inserted directly inside existing HTML tags 
91 or attributes 92. This is exposed syntax: That is, the field names 82 will show up 
on input page 15 during design time. This kind of syntax makes it easier for the 
designer to tell where the dynamic content is located, but makes it harder to get a 
sense of what the actual run-time page will look like. In addition, in exposed 
15 syntax, any dynamic links, images, or other page properties may appear broken 
to the designer until the actual run- time page is served. Generic tag content 90 
illustrates the use of an exposed, specially prefixed fieldname 82 inserted between 
two tagnames 91. Generic tag attribute 92 shows use of a specially prefixed 
fieldname 82 as an attribute 92. 

20 Figure IE shows the use of hidden syntax. In this syntax, field names 82 are 

hidden as either generic tag content 100 or generic tag attributes 102. With hidden 
syntax, the designer is free to use "dummy" data throughout input page 15 for a 
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better sense of how the runtime document will look. At run-time, the actual 
values of the field names 82 will be supplied. 

In most present browsers designed for the Worldwide Web, a browser does not 
send the web server the same information that it receives from a web server. 
5 When sending information, the browser sends only the information in a URL 
(Uniform Resource Locator) and a simple list of HTML parameters and their 
values. These are either attached to the URL or are sent separately along with the 
URL when submitted from a Form using the "POST" method. See Figure 4A(Prior 
Art).Thus, if a page has both queries and updates, the specially prefixed fields will 

10 be used by the present invention to populate data into web pages that are served. 
However, the browser at the user's location doesn't send back those same fields 
- to the web server when it submits the form, because HTTP does not permit them. 
Instead, the browser only sends back the HTML parameter list based on the 
names defined in the HTML FORM. These parameter names are standard HTML 

15 and do not use or need the special prefix syntax of the present invention. 

The present invention supports this situation by allowing one set of mappings to 
be active when the web page is served from a query, and a different set of 
mappings to be active when a form is used to update. On the query, the 
invention maps the specially prefixed fields. On a form update, the invention 
20 maps the HTML parameters defined by the form. The present invention also 

allows a query definition to set default values, attributes, and selection lists for all 
the form's fields, as well as the form's action attribute and other page properties. 
Other client programs, such as special Java application programs can send back 
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data in any format, including files, which can also be handled by the present 
invention. Usually, such special programs will use the same sets of fields as the 
input page. 

Turning now to Figures 1F-1J, the syntax and context analysis used by the present 
5 invention to format repeating fields is illustrated. When a user is accessing 

dynamic data from a database, the same field in a document may be repeated in 
the display document multiple times, each time having a different value. 

When the virtual server of the present invention (discussed in more detail below) 
creates an XML document from back-end data, (database 00) at run-time, it may 
10 repeat the same field in that document multiple times, each time with a different 
value. To format these repeated fields, the DCI 18 of the present invention 
generates, at design time, style sheets 25 capable of repeating both the fields and 
the surrounding HTML formatting tags. 

DCI 18 also allows nesting of repeated fields and formatting within other 
15 repeating fields and formatting. A designer controls repeating formatting for 
fields based on placement of the fields in an HTML page and on the structure of 
the hierarchical node names shared by the repeated fields. DCI 18 and virtual 
server 54 of present invention analyze the prefixes and the context of these 
formats to determine the repeat patterns. 

20 In Figure IF, the method for repeating table rows is shown. In the embodiment 
shown, all fields share a common root node which associates all fields with their 
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parent document. Since this node is automatically part of all field names and 
designers do not usually enter it, it is not considered or shown in the examples 
below. In Figure IF, a table row is repeated once for each time the first node 
(reading the field left to right) is shared by all repeating fields in the row. Any 
5 static text in the row repeats when the row repeats. All row and cell attributes 
(such as border and background color) also repeat. 

In Figure IF, table 114, only the second row 112 has a specially prefixed fieldname 
82. The fieldname 82 has a single node Nl called here "itemfeature". The second 
row will therefore be repeated once for each occurrence of "itemfeature" in the 
10 run-time XML document. 

Thus, as shown by table 116 of Figure If, if there is only one actual occurrence of 
an "itemfeature" (here the actual itemfeature is "It's cheap!) when the backend 
data from the database is served by server 54 in an XML format, then the example 
of row 120 will be displayed when the page is served. However, if the field has 
15 several entries in the database, the present invention allows the field formatting to 
be repeatedly applied to them, as seen in Table 118 , rows 122-126 of Figure IF. 

With reference now to Figure 1G, the present invention allows a web page 
designer to repeat the formatting for multiple fields sharing the same node. In 
table 130, as it appears at design time, row 132 has two static fields (Product Name 
20 and Product Features) and row 134 has two dynamic fields, as indicated by the 
special prefix 82, psx in this example. The formatting specified by the designer for 
these fields will be as seen at runtime in Table 140, when the dynamic data for 
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them has been retrieved and served. Here, the static row 142 is not repeated, but 
for each dynamic occurrence of a product name, one or more product features 146 
are shown and formatted as originally specified by the web page designer. Each 
product appears on a new row and within that row the features are listed. It 
5 should be noted in these examples, that the formatting shown here which includes 
the prefix and node names is the formatting defined by the designer at design 
time - -in Figure 1G, that is table 130. The results - -here table 140 of Figure 1G- - 
are provided by virtual server 54 of the present invention in a display document 
in response to that formatting and to the actual results from database 00. 

10 Turning now to Figure 1H, it can be seen that the embodiment shown also allows 
repeating of rows within rows. In Figure 1H , table 150 is defined at design time. 
In table 150, the outermost table row 152, repeats for the first shared node Nl 
(from left to right), the second table row 154 inward repeats for the second shared 
node N2 (continuing to right) and so on continuing inward until either all nested 

15 tables or shared nodes are exhausted. This formatting is described by DCI in an 
XSL style sheet and the dynamic data is identified by DCI 18 in a DTD format 
dynamic content definition 28. When dynamic data is retrieved at runtime about 3 
different productsl58,162,164, each having one or more featuresl70,172,174,176, 
the XSL style sheet 25 and the dynamic content definition 28 created at design 

20 time are applied by the invention's virtual server so that the information is 
displayed as shown in table 156 of Figure 1H . In Figure 1H note that the static 
content 160 'Take a look at these features!" is repeated with each occurrence of 
the product/name, while the changeable, dynamic content about products and 
features has been arranged as shown in Table 156. 
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All other repea table formats nested within a table, such as the bulleted list shown 
in Figure II, , exhaust the shared nodes (from left to right) in the order of 
outermost to innermost repeatable formatting. Those skilled in the art will 
appreciate that other methods for analyzing the context and syntax could be used 
without deviating from the present invention. Special characters or indicators 
could be used, for example, or context might be analyzed differently. 

Figure 1J illustrates how the DCI 18 of the present invention can be used to format 
forms from a browser, applying the same analysis. 

Now turning to Figure IB, virtual server 54 of the present invention is shown. In 
the embodiment shown, a standard web server 52, such as Microsoft 
Corporation's Internet Information Server (IIS) web server is used, and 
Microsoft's standard Windows NT™ operating system 50 is used as well. As will 
be apparent to those skilled in the art, other web servers, operating systems, and 
network protocols could be used without deviating from the spirit of the present 
invention. Figure IB illustrates the relationship of the invention's design time tools 
- -data access page request definition generator 19 and web page designer's DCI 
18- - with actual runtime programs, such as the present invention's virtual server 
54, and other web applications 60, web browser 70, and database 00. 

Turning briefly to Figure 4B, an overview of the operation of virtual server 54 of 
the present invention is shown. When a query request is made from a user at UU, 
it is translated by the web browser into standard http protocol requests S5, such as 
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GET URL, POST Body, and forwarded to the webserver machine S15. There the 
webserver 52 maps the URL to find the predefined request object handler 32 of 
the present invention's virtual server 54. Predefined request object handler 32 
uses the dynamic content definition 28 created at web page design time in DTD 
5 format, and data access definitions 32b created at data access design time to find a 
database 00, to get the data at block 25, and then to generate the reply in XML 
format that will be combined by virtual server 54 with the previously defined XSL 
style sheet to create a web page display document DD that has all the dynamic 
fields requested and formatted as the web page designer intended. 

10 In the embodiment shown, virtual server 54 automatically generates and serves 
virtual, hierarchically structured documents from structured data stored in a 
variety of data schemas (relational, tabular, indexed, hierarchical) in a database 00, 
In addition, all data transformations necessary to map from the storage schema 
of database 00 into the front-end display document DD hierarchy schema may be 

15 defined visually without the need for any code, (as described below) thus 

simplifying the data access logic as well. The data retrieval and data processing 
logic are pre-compiled and optimized when the virtual server 54 process is started. 
No run-time code is generated nor is any code interpreted while processing run- 
time requests. The transformation mappings done by virtual server 54 allow 

20 structured data organized in rows and columns to be automatically repeated or 
collapsed as necessary to fit a hierarchical document's content structure. 

In the embodiment shown, no physical input page 15 was actually stored on disk 
at design time by DCI 18. Instead, an input web page 15 in the present invention 
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is a virtual document described by XSL style sheet 25 and dynamic content 
definition 28. Consequently, in the present invention, a request for such a 
virtual document appears the same (uses the same request syntax) as a request for 
an actual physical document being served from disk, although the document in 
5 the case of the present invention is entirely virtual. Because the document is 
virtual, no physical web page document need be stored on, or requested from 
disk in order for the final display document DD to be served. 

In other words, while prior art approaches usually store a physical document r - 
such as input page 15- - containing HTML formatting and embedded code , the 
10 present invention's virtual server 54 generates a virtual document at runtime, 
based on the parameters stored in the predefined request definition object data 
access definitions 32b and XSL style sheet 25. 

Virtual server 54 of the present invention both generates and serves XML and 
HTML documents via the HTTP protocol from various back end data sources- - 
database 00 - -including relational SQL (Standard Query Language) databases, 
other XML or HTML files, hierarchical databases (AS/400), and file systems, 
among others. This allows the data access logic and design to be completely 
separated from the "look and feel" of the web page design. Returning to Figure 
1A for a moment, page request definition generator 19 is used by the data access 
designer to create the data access definitions 32b that are stored in page request 
object data access definitions 32b. 



15 



20 



Now referring to Figure 4C, when a request R is made by a user UU, it travels 
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using standard HTTP protocol over the Internet II to computer SI 5, which is 
running an operating system 50, a webserver 52 and the present invention's 
virtual server 54. Virtual server 54 executes the page request object handler 32 
which is associated with the fields in the request R, and uses the data access 
5 definitions 32b, which were created by the page request definition generator 19, to 
access database 00 and find data 01 which meets the request R. The data access 
definitions 32b can be defined to work with data 01 in a number of common 
formats, or schemas, such as relational databases, flat fields databases and so on. 
The data access definitions 32b are used to find the database 00 and make the 
10 appropriate read or write requests against it. 

In the embodiment shown in Figure 4C, virtual server 54 maps the data 01 found 
into XML format using the dynamic content definition 28 created by DCI 18 at 
web page design time. As part of this processing, the formatting defined in style 
sheet 25 is applied to both the dynamic and the static content of the data found 

15 and the virtual display document DD being created. When formatting is 

completed, virtual web page display document DD is sent back to the user UU 
over the Internet II, using the standard webserver software 52. As seen in this 
example, display document DD is not stored at the webserver site or in the 
database 00 but is created dynamically in accordance with the parameters that are 

20 stored in page request object XML mappings 32a and data access definitions 32b, 
XSL style sheet 25 and dynamic content definition 28. In the embodiment shown, 
page request object handler 32 includes handler code which accepts the 
information in the data access definitions 32b, dynamic content definition 28 and 
XSL style sheet 25 as parameters to be used in satisfying the request R. Thus, no 
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code is embedded in display document DD. This makes it easy for the data access 
logic to be changed without affecting the web page formatting and vice versa. 

In addition, the mapping to XML format performed by the invention 's virtual 
server 54 is also simplified by use of the current invention's visual mapper 33, 
5 shown in Figure 4D. As seen there, the data access designer can use visual mapper 
33 to specify how data 01 found in database 00 should be mapped into XML fields 
and formats stored in XML mapping 32a. Since this mapping is done at data access 
design time, it turns the actual mapping at runtime into the application of 
predefined parameters. 

10 Turning back briefly to Figure 1G, an example of XML 141 generated by page 
request object handler 32 in virtual server 54 of the present invention is shown. 
When page request object handler 32 applies the XSL style sheet 25 formatting, 
and the dynamic content definition 28 at runtime, the results will appear as table 
140 when that particular request is handled. 

15 With reference now to Figure 1A again, page request definition generator 19 of 
the present invention is used by the data access designer, at design time to create 
data access definitions 32b of the page request object handler 32. Thus, at run 
time, page request object handler 32 will have as input parameters the XML 
mapping resulting from dynamic content definition 28 and the data access 

20 definitions 32b, as well as XSL style sheet 25. 

This enables virtual server 54 of the present invention to take advantage of the 
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dynamic content definition 28 to determine what the output format should be. 

Dynamic content definitions 28 can also contain information regarding the 

repetitiveness of the data elements. For instance, if there is a table in database 00 

called orders with the following structure: 

5 order Jd Item 

123 1 

123 2 

123 3 

456 1 

10 456 2 

there are many ways to create an XML document from this data. One way to 

force the structure is to build the dynamic content definition 28 in the appropriate 

manner. For example: 

<!ELEMENT Orders (Order*)> 
15 <!ELEMENT Order (ItemList)> 
<!ATTLIST Order 

id ID #REQUIRED> 
<!ELEMENT ItemList (item*)> 
<!ELEMENT item (#PCDATA)> 

20 This has Orders as a root node which contains Order elements. Looking at the 
above dynamic content definition 28, there is an asterisk next to Order in the 
Orders element declaration. This indicates that Order is a repeating entry. Order 
contains a single attribute, the order id. That maps to an order Jd column. There is 
also an ItemList element which contains item elements. The item elements map to 
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the item column. Once again, from the dynamic content definition 28 it is seen that 
item is a repeating entry. The id attribute, on the other hand, cannot repeat, 
because attributes cannot repeat in XML. Based upon these relationships, the 
present invention makes a few determinations: 

5 - -the id attribute of the Order element must be the identifier for item entries. This 
means that for each matching id (orderjd in the back-end) the invention creates 
one ItemList entry. It then collapses multiple item entries into their matching 
ItemList entry. 

Since the id attribute (order_id column) is the key, the back-end query must be 
10 sorted on order Jd. If "Use WHERE table" is specified in the data selector on the 
query pipe and no sorted columns have been specified, the present invention will 
define orderings (ORDER BY) in the SQL statement issued to the back-end 
database 00. If sorted columns have been specified, or "Manually enter SQL" has 
been chosen, the user must be sure to properly sort the data. In the above 
15 example, the user wants to collapse items based upon their order id. 
Consequently, the invention will sort on the orderjd column. 

This would cause the following XML to be generated: 



<Orders> 

<Order id="123"> 
20 <ItemList> 

<item>l</item> 
<item>2</item> 



WO 01/1 8656 PCT/US00/2469S 

-25- 

<item>3</item> 
</ItemList> 
</Order> 
<Orderid="456"> 
5 <ItemList> 

<item>l</item> 
<item>2</item> 
</ItemList> 
</Order> 
10 </Orders> 

If a slight change is made as follows, to the dynamic content definition 28 : 

<!ELEMENT Orders (Order*)> 
<!ELEMENT Order (item)> 
<!ATTLIST Order 
15 id ID #REQUIRED> 

<!ELEMENT item (#PCDATA)> 

once again Orders is a root node which contains Order elements. Order contains 
the order id, but now it contains the item element directly. This structure indicates 
there are repeating Order elements, but id and item are now a one to one match. 
20 For this model, the invention makes no assumptions about sorting requirements. 
It would now generate the following XML: 
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<Orders> 

<Orderid= , 123 ,, > 

<item>l</item> 
</Order> 
5 <Orderid="123"> 

<item>2</item> 
</Order> 
<Orderid= ,, 123 ,, > 

<item>3</item> 
10 </Order> 

<Orderid= ,, 456 ,, > 

<item>l</item> 
</Order> 
<Orderid="456"> 
15 <item>2</item> 
</Order> 
</Orders> 

Further complicating query mappings, the data may contain conditionals which 
can change the way data is mapped. For example, assume the data contains a 
20 phones table as follows: 

phone_id conMd phone_type phone_no 
1 1 H 111-1111 
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2 1 B 222-2222 

3 1 F 333-3333 

4 2 B 444-4444 

5 2 F 555-5555 

5 and the following dynamic content definition 28 is generated: 

<!ELEMENT Contacts (Contact*)> 
<!ELEMENT Contact (Phones)> 
<!ATTLIST Contact 

id ID #REQUIRED> 
10 <!ELEMENT Phones ((home | business | fax)*)> 
<!ELEMENT home (#PCDATA)> 
<!ATTLIST home 

id ID #REQUIRED> 
<!ELEMENT business (#PCDATA)> 
15 <!ATTLIST business 

id ID #REQUIRED> 
<!ELEMENT fax (#PCDATA)> 
<!ATTLIST fax 

id ID #REQUIRED> 

20 In this example, first note that the Contacts/Contact element is repeating. It's id 
attribute maps to the cont_id column. This tells the present invention it will be 
sorting on cont_id and collapsing phone records into the Phones element. The 
pipe character in the Phones element declaration signifies that the Phones element 
contains home, business or fax elements. Furthermore, the asterisk signifies that 

25 there may be many of these. To get the phone numbers into the appropriate 
places, the data access designer builds a mapping such as the following: 



XML Field 

Contacts/Contact/@id 



Back-End Column Conditionals 

cont_id 
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Contacts/Contact/Phones/home/@id 
H 

Contacts/Contact/Phones/home 
H 

5 Contacts/Contact/Phones/business/@id 
B 

Contacts/Contact/Phones/business 
B 

Contacts/Contact/Phones/fax/@id 
10 F 

Contacts/Contact/Phones/fax 
F 



phone_id 



phone_no 



phone_id 



phone Jd 



phone_no 



phone_no 



phone_type = 



phone_type = 



phone_type = 



phone_type = 



phonejype = 



phone_type = 



As the invention processes the data, in the embodiment shown, it will first create 
the Contacts/Contact element and set the id to the cont_ id column value. For each 

15 matching conMd value, it will then look at the conditionals phone_type column 
value to determine what to do. If the column contains 'H' as it's value, it will create 
a Contacts/Contact/Phones/home element containing the phone_no column's 
value and set the id attribute to the phone_id column's value. If the phone_type 
column contains 'B' or 'F it will create the business or fax element in the same 

20 fashion. Based upon the data specified above, the following XML document is 
generated: 

<Contacts> 



<Contactid=T'> 
<Phones> 



25 



<home id=T'>lll-llll</home> 
<business id="2">222-2222</business> 
<fax id="3">333-3333</fax> 
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</Phones> 
<Contact> 
<Contactid= M 2"> 

<Phones> 

5 <business id="4">444-4444</business> 

<fax id="5">555-5555</fax> 
</Phones> 
<Contact> 
<Contacts> 

- 10 -When performing updates/inserts or deletes, the embodiment of the invention 
shown here needs an attribute or element to be defined which tells it which of 
these three actions it should take. 

Unlike query mappings which take advantage of the dynamic content definition 
28, update mappings rely heavily upon the XML mapping definitions 32a and the 
15 input data structure. For example with the following XML document: 

<Contacts> 

<Contactid='T'> 

<Phones DBActionType="UPDATE"> 

<home id= M l n >lll-llll</home> 
20 <business id= , 2">800-222-2222</business> 

<fax id="3">333-3333</fax> 
</Phones> 
<Contact> 
<Contactid="2"> 
25 <Phones> 

<business id="4">444-4444</business> 
<fax id="5">555-5555</fax> 
</Phones> 
<Contact> 
30 <Contacts> 
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there is an added attribute, DBActionType, to the Phones element. When 
performing updates, inserts or deletes, the page request object handler 32 of the 
present invention needs an attribute or element to be defined which tells it which 
of these three actions it should take. The system would then see a need to 
5 update the phone numbers for the first contact, but skip the second contact. 

This entails applying data from multiple XML fields into the same back-end table. 
To do this, the data access designer has created a set of mappings for each XML 
group to its corresponding back-end group. By repeating the back-end column 
entries, the present invention will process each group of entries as a separate 
10 update to the back-end database 00. 

Enabling users to navigate, link, or "drill down" from one page to the next is also 
provided for by the present invention. In its simplest form, the data access 
designer can simply use a request URL on the "source" (current) page to point to 
the next successive "target" page. However, in a dynamic environment things 
15 quickly get more complicated. The request URL to the' target" page needs to 
supply more information in order to get the right type of dynamic content. 

For example, in a static environment with only one person, the request URL needs 
to only specify "person.htm" but in a dynamic content environment with many 
people, the URL would need to specify 
20 n person.htm?firstname=Joe&lastname=Smith" in order to get the exact person 
page for "Joe Smith". 
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Complicating issues further, the source page may itself have been created 
dynamically based on some other request. Suppose for example, the source page 
contained a list of people to choose from by name, but now the target page 
required an employee ID number to locate any specific person such as, 
5 "person.htm?employeeid=123". Here, though the source page is designed to 
show 

people by name, it would have to "know ahead of time" that it is linked to a 
target page which requires the employee ID number and not the person's name. 
Otherwise, the source page would be delivered without the employeelD and it 
10 would not be possible to link it to the target page. Furthermore, if the target 
page is changed to use something other than employee ID, then the source page 
would have to be kept in synch or the links could be broken. 

The present invention solves these problems through the use of navigation links. 
As seen in Figure 14, the data access designer visually links the "source" data 

15 request 1400 to all the other possible "target" data requests, 1402,1404,1406 etc., 
that could be linked to from that source. When this is done, the "source" request 
handler auto-generates all the possible URLs required to link from the source web 
page to the target pages. Each of these URLs are placed in the "source", in addition 
to the other data defined by that source request. If a linked target resource 

20 definition is altered to require a new type of request URL, the source request 
handler is also altered so as to generate the new URL to the target resource. 



These autogenerated URLs may be used however the designer wishes in the 
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actual 

pages returned. Most often, the URL is placed as the contents of the HREF 
attribute on the A (anchor) tag to allow for hypertext linking between 
documents. However, it is also commonly used in the SRC attribute of the IMG 
5 tag (for navigation links attached to non-text resources), or the ACTION 
attribute of the FORM tag (for navigation links attached to update resources), 
or anywhere else a standard URL is used in an HTML page or other client 
application. 

When a "source" request is linked to a "target" request at design time, the 
10 subsequent request handler for the "source" is created with additional properties 
as follows for each linked target. In the embodiment shown, the "source" request 
must always be a query. 

1. The target request definition is examined to determine any required request 
parameters. 
15 2. If the target is a query: 

a. The data selection properties for the target are determined. 

b. Required data for selection is mapped to request parameters for the URL 

c. The source request handler is updated to include processing of the 
additional parameters into valid URL syntax. 

20 3. If the target is an update the links may be defined to allow updates, 
inserts, or deletes. There are two cases to be considered: 
a. URLs for inserts 

i. Only the request properties for the target are mapped to request 
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parameters for the URL. 

ii. The source request handler is updated to include processing of the 
additional parameters into valid URL syntax, 
b. URLs for updates or deletes 
5 i. The data update properties for the target are determined. 

ii. Required key data for the update is mapped to request parameters 
for the URL 

iii. The source request handler is updated to include processing of 
the additional parameters into valid URL syntax. 

10 At run time, the request handler for the "source" page now includes the 

necessary mechanisms to generate all the URLs to each linked target. When the 
source page is processed, the additional URL generation takes place, and the 
URLs are included with the source document when it is served. 

Detailed flow diagrams illustrate the logic of the embodiment shown. Beginning 
with Figure 15, DCI 18's processing of the HTML nodes is shown. An input page 
15, here shown as HTML 1500 is analyzed HTML node by HTML node, as 
illustrated at step 1502. Once an HTML node is selected, DCI 18 checks to see if it 
has child nodes at decision block 1504. If it does, DCI 18 loops through each HTML 
childnode until the last or innermost is found. When that is found, processing 
proceeds at step 1510, to process all the HTML node information from static text at 
1512, to other attributes at 1538. The prefix and context analysis described above 
is applied to each, as appropriate. Then DCI 18 corrects the node context at step 
1540, transforms the HTML node to an XSL node at 1510, and replaces the older 
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20 
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one, if any. Processing continues in this manner at 1506 for each HTML node in 
the child node list. When processing is completed, an XSL style sheet 25 and a 
dynamic content definition 28 have been created. 

Turning now to Figure 5, initiation of the invention's virtual server 54, here 
5 referred to as E2 is shown. At step 500 the webserver hook of virtual server 54 
receives a request. At decision block 502 it checks to see if the URL specified in the 
request is in this server's root. If it is not, the event is released untouched at step 
504. If the request does have a URL contained in virtual server 54's root, the 
invention checks to seek if there is at least on application also in the root, and if the 

10 rest of virtual server 54 is up and running. If not, the event is either released at 
step 508, or the checks for maintenance processing at step 512 through 522 are 
executed. If virtual server 54 is up, the request is handed to its dispatcher at step 
520. At step 524 the input parameters of the request are parsed and then run 
through virtual server 7 4's request filters, shown below. Checks are made to see if 

15 the request is tied to an application, or if SSL (Secure Socket Layer or other 

encryption technology is required) and appropriate reports are generated. At step 
542, the invention can check use statistics to select the most available server for 
handling the present request and forward the request to that server. 

Figure 6 is a flow diagram which illustrates some of the pre-processing of the 
20 request done by the present invention. At decision block 602, the system checks 
to see if raw input data exits have been defined by the user, and if they have, an 
exit handler is executed for each one specified at step 610. Exits, as they are defined 
in the embodiment shown, are custom code a data access designer may have 
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written. While it is a goal of the present invention to minimize the need for any 
custom code, it also permits such code to be included by a data access designer, if 
desired. If no special exits are need, the invention proceeds to step 604 to map the 
input data in the request to the back-end data in database 00, by mapping names, 
5 and converting data types as necessary. If this succeeds, processing flows to the 
statement builder at step 618. 

The statement builder of the present invention is shown in Figure 7. Essentially, 
the statement builder determines what kind of data access is required. As seen at 
block 710, if a simple query is required, processing proceeds to execute the query 
at step 718. If an insert is requested, that processing is selected, and so on. Figure 
8 illustrates the processing to execute a query, Figure 10 illustrates the logic for 
inserting data, Figure 12 illustrates update processing, and Figure 13, delete 
processing. Figure 11 shows the processing of an actual transaction against 
database 00, and Figure 9 illustrates the generation of the results. As seen at step 
926 in Figure 9, the results are the generated HTML display document DD. 

In the embodiments shown, Windows NT- compatible personal computers and 
workstations are used to implement the present invention. However, those skilled 
in the art appreciate that other computer platforms such as SUN Microsystems 
workstations, or IBM Mainframes could be used as well, either in client server or 
20 centralized or distributed network configurations. While the embodiments shown 
are programmed using C++, other programming languages can be used as well. 
Similarly, while software has been used along with the above computer systems 
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to implement the invention, part or all of the invention could be included in 
firmware or hardware circuitry without deviating from the spirit of the present 
invention. 



WO 01/1 8656 PCT/US00/24695 

Claims 

What is claimed is: 

1. A method for generating a virtual display document containing dynamic 
content over a network in response to a request, comprising the steps of: ' 

5 accessing dynamic data in a database using a previously generated dynamic data 
access definition; 

applying a previously generated style sheet to format the static fields of the virtual 
display document; 

applying a previously defined dynamic content definition for the virtual display 
10 document which describes how dynamic fields are to be formatted; and 

dynamically serving a virtual display document formatted accordingly in response 
to the request. 

2. The method of Claim 1, wherein the step of accessing dynamic data in a 
database using a previously generated dynamic data access definition further 

15 comprises the step of using the data access definition to find the database and 
make the appropriate input and output requests to the database. 

3. The method of Claim 1 wherein the step of accessing dynamic data in a 
database using a previously generated dynamic data access definition further 
comprises the step of using the previously generated dynamic data access 

20 definition to work with data in any of a plurality of common formats. 

4. The method of Claim 1, wherein the step of dynamically serving a virtual 
display document further comprises the step of mapping data access definitions, 
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style sheets and dynamic content definitions to generate the virtual display 
document. 

5. The method of Claim 4, wherein the step of mapping data access definitions, 
style sheets and dynamic content definitions further comprises the step of 

5 mapping data access definitions, style sheets and dynamic content definitions into 
XML format. 

6. The method of Claim 4, wherein the step of mapping data access definitions, 
style sheets and dynamic content definitions is performed dynamically by a page 
request object handler. 

10 7. The method of Claim 6, wherein the step of mapping data access definitions, 
style sheets and dynamic content definitions further comprises the steps of: 
- - mapping the correspondences between data access definitions, style sheets and 
dynamic content definitions and XML fields and formats at design time and 
storing the mapping results in the database; and 

15 - -using the page request object handler to apply the mapping results when the 
virtual display document is served. 

8. The method of Claim 7 wherein the step of mapping the correspondences is 
done by a visual mapper. 



20 



9. An apparatus for generating a virtual display document containing dynamic 

content over a network in response to a request, comprising: 

means for accessing dynamic data in a database using a previously generated 
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dynamic data access definition; 

means for applying a previously generated style sheet to format the static fields of 
the virtual display document; 

means for applying a previously defined dynamic content definition for the 
5 virtual display document which describes how dynamic fields are to be formatted; 
and 

means for dynamically serving a virtual display document formatted accordingly 
in response to the request. 

10. The apparatus of Claim 9, wherein the means for accessing dynamic data in a 
10 database using a previously generated dynamic data access definition further 

comprises means for using the data access definition to find the database and 
make the appropriate input and output requests to the database. 

11. The apparatus of Claim 9 wherein the means for accessing dynamic data in a 
database using a previously generated dynamic data- access definition further 

15 comprises means for using the previously generated dynamic data access 
definition to work with data in any of a plurality of common formats. 

12. The apparatus of Claim 9, wherein the means for dynamically serving a virtual 
display document further comprises means for mapping data access definitions, 
style sheets and dynamic content definitions to generate the virtual display 

20 document. 



13. The apparatus of Claim 12, wherein the means for mapping data access 
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definitions, style sheets and dynamic content definitions further comprises means 
for mapping data access definitions, style sheets and dynamic content definitions 
into XML format. 

14. The apparatus of Claim 12, wherein the means for mapping data access 

5 definitions, style sheets and dynamic content definitions is performed dynamically 
by a page request object handler. 

15. The apparatus of Claim 14, wherein the means for mapping data access 
definitions, style sheets and dynamic content definitions further comprises: 
means for mapping the correspondences between data access definitions, style 

10 sheets and dynamic content definitions and XML fields and formats at design time 
and storing the mapping results in the database; and 

means for using the page request object handler to apply the mapping results 
when the virtual display document is served. 

16. The apparatus of Claim 15 wherein the means for mapping the 
15 correspondences is a visual mapper. 
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